Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.92%. Comparing base (d7e5434) to head (c4b8c00).
Report is 4 commits behind head on master.

@@            Coverage Diff             @@
##           master     #808      +/-   ##
==========================================
+ Coverage   94.89%   94.92%   +0.02%     
==========================================
  Files          49       49              
  Lines        7478     7502      +24     
==========================================
+ Hits         7096     7121      +25     
+ Misses        382      381       -1     

clang-tidy review says "All clean, LGTM! 👍"

I am wondering if we could draw some inspiration from LLVM's BitmaskEnum?

I am wondering if we could draw some inspiration from LLVM's BitmaskEnum?

I went through their code and read about the BitmaskType in C++?
To confirm, using this approach, we will have 2 benefits:

• Setting of bit only possible through clad::opts::... enum and not through some other unrelated enums or integer literals.
• This can help in a single bit for tbr analysis? Disabling using ~clad::opts::tbr_analysis (no separate enable or disable).

Is this correct? If so, I think yeah, we should have an interface using this approach.

I am wondering if we could draw some inspiration from LLVM's BitmaskEnum?

I went through their code and read about the BitmaskType in C++? To confirm, using this approach, we will have 2 benefits:

• Setting of bit only possible through clad::opts::... enum and not through some other unrelated enums or integer literals.
• This can help in a single bit for tbr analysis? Disabling using ~clad::opts::tbr_analysis (no separate enable or disable).

Is this correct? If so, I think yeah, we should have an interface using this approach.

Wouldn't ~clad::opts::tbr_analysis correspond to "all options enabled except for clad::opts::tbr_analysis"? This would work if we took the bitwise & with this option. But we take the bitwise | which will only lead to all other options being enabled.

Wouldn't ~clad::opts::tbr_analysis correspond to "all options enabled except for clad::opts::tbr_analysis"? This would work if we took the bitwise & with this option. But we take the bitwise | which will only lead to all other options being enabled.

Ah, Good catch, thanks for pointing this out.
Then, yeah, we should have two separate options only (enable, and disable).
Still, I will add some changes for the first benefit - type safety.

I am wondering if we could draw some inspiration from LLVM's BitmaskEnum?

My bad, I forgot that we are using the first few bits of this same mask for derivative order too (which is unsigned int or a separate enum order). So, we can't have strict typing :(.

clang-tidy review says "All clean, LGTM! 👍"

@vaithak, @PetroZarytskyi is that ready to go?

I have addressed the requested changes, @PetroZarytskyi if this looks good to you then we can go ahead.

The PR looks good to me. Thank you for the work!